1. Field of the Invention
The present invention relates generally to methods for defining relationships between, and operating graphical objects.
2. Description of Related Art
A user interface is a configuration of widgets conjoined with logic managing how each relates to data and interacts with other widgets for the purpose of facilitating dataflow, workflow, and ultimately program flow. The purpose of a user interface (“UI”) is to provide the user with data visualization, selection capabilities, and command mechanisms. The combination of these functions and how they interrelate facilitates workflow, dataflow, and program control flow inherent to an application. User interface widgets facilitate data representation by rendering data, editing data, and/or providing lists of data items. Many widgets are selection sensitive and provide the capability to select sets of data items that can then be operated on when commands are issued to do so. These commands originate from command sensitive widgets. In conventional usage, user interface objectives and requirements may not be fully addressable because of the difficulty associated with meeting these objectives and requirements using source code.
In a conventional UI paradigm, user interface widgets are generally divided into four types:    1. Visualization widgets that are typically read-only widgets that render text, graphics, or some other representation of data; visualization widgets generally do not allow a user to directly modify or change displayed data.    2. Selection-based widgets that primarily visualize selection state, which may involve providing a visualization of data items, and may furthermore allow manipulation of the selection state.    3. Command-based widgets that simply inform user interface logic that the user wants to perform a specific operation on data selected in the current selection context.    4. Combination widgets that provide some amount of each of the visualization, selection-based and command-based widgets. For example, an edit box visualizes text, allows selection thereof, and issues commands to insert characters, delete characters, copy and paste.
Generally speaking, most widgets have some amount of visualization associated with them. For the purposes of categorizing widgets, a widget's primary function determines the widget type. Table 1 lists some commonly used widgets and their primary function:
TABLE 1VisualizationSelectionCommandCombinationStatic textCheck boxButtonEdit Control (selectionGroup boxRadio buttonand command)PictureCombo boxMenu (selectionList boxand command)Scroll barCustom controlSliderProgress bar
A conventional UI paradigm groups all widgets into the “Command” category so that each widget issues commands and/or notifications indicating what the widget is doing. It is then the responsibility of the application developer to manage these notifications in order to create the intended widget behavior as described by the categories above. The conventional paradigm additionally includes the concept of aggregate widgets including, for example, tab controls or property sheets. This concept embodies an aggregation of widget primitives and would be better described as a widget configuration rather than a widget itself.
A commonly used conventional paradigm for selection management depends on having a distributed selection context for the UI where each widget internally stores and maintains the selection state relevant to that widget. This paradigm is used primarily because selection information is needed during widget rendering and also when interacting with a user when it is desirable to have the selection information at hand within the widget to facilitate widget rendering and user interactions.
Furthermore, each widget has a well-defined purpose and can only display certain types of data resulting in a rigid interface for transferring data to/from the widget as well as manipulation of the internal selection state. The standard set of widgets generally only support primitive data types such as a string, a number, etc. or collections thereof. A widget typically has a primary purpose of displaying data in a form understandable by a software user. Thus, each widget is typically connected in some way to data storage for the purpose of displaying that data, which can involve writing to data storage as well as reading (in the case of editing data).
Data storage is data having unknown structure for which the user interface is being constructed and the structure is at least unknown to a widget toolkit builder. Since only the simplest data storage is directly compatible with conventional widget interfaces, a mediator is needed to provide the “translation” and data path between widgets and their data storage. This data flow process between widgets and data storage is known as data binding. To facilitate software workflow and dataflow, mediators perform a variety of tasks that can be divided into four groups:
1. Data transfer facilitating a data path between widgets and their data sources in addition to querying widget selection states in order to decide what data to provide or otherwise access at any moment.
2. Widget event handling related to data and/or to selection context and encompassing management of widget selection state and interdependent states of widgets; this may also include providing new data to widgets when a change in selection state requires different data to be displayed in any widget.
3. Widget event handling related to command and control and encompassing actions directly related to performance of operations on data by widgets based on the current selection context. Typically, this involves receiving an event and then having to query widget selection states in order to determine how to best handle that event.
4. Miscellaneous event handling and control flow encompassing program flow, configuration changes, data management, layout resizing, and other miscellaneous tasks most likely related to workflow, dataflow, and control flow.
FIG. 1 shows how these duties relate to one another under the conventional paradigm. In general, selection-state management and data delivery to and from widgets is handled by a mediator. Some widget toolkits provide direct data transfer, whereby data transfer is handled independently from the mediator, thereby alleviating some data binding issues. However, direct data transfer still requires the mediator to manage widget selection state for the UI.
In particular, FIG. 1 illustrates conventional data binding of widgets (101 to 104) to the data storage 110 they represent. Widgets (101 to 104) are connected to data storage 110 through a process managed by the mediator 105. Mediator duties 106, 107, 108, and 109 facilitate dataflow, workflow, and program flow for a user interface. The user interacts with the widgets which send events to the mediator 105 that are handled depending upon nature of the event. This involves managing events related to: i) selection changes 106 and how that affects widgets dependent on that change; ii) command, control, or program flow 107 operating on selected data; iii) miscellaneous event handling and program flow control 108; and iv) data transfer 109 which moves data between the widgets (101 to 104) and the data source 110 depending upon the selection context, which is distributed among the widgets.
The main difficulty regarding the UI mediator, in terms of software development, lies in having to implement the logic driving widget selection-context management and bound data. This is primarily rooted in the conventional paradigm having a distributed selection context requiring the mediator to query widget selection states for nearly every logic step.